Whitepaper on how to write a LabVIEW compatible DLL?

[John Lokanis]

I am looking for a whitepaper or other document that spells out (to a C programmer in their own terms) how to write a DLL that can be easily called by LabVIEW. I have searched NI for this but have not found quite what I was looking for. Can someone point me in the right direction?

thanks,

-John

[Rolf Kalbermatter]

I am looking for a whitepaper or other document that spells out (to a C programmer in their own terms) how to write a DLL that can be easily called by LabVIEW. I have searched NI for this but have not found quite what I was looking for. Can someone point me in the right direction?

This request is a little very much open ended. Should this be about a DLL that can be interface only by LabVIEW or should it also be possible to call it by other applications (VB, C, Delphi, etc)?

If it is just about a LabVIEW compatible DLL, is it legitimate to have LabVIEW specific parameters (advantage: direct parameter passing, disadvantage: call to specific LabVIEW manager functions that the C programmer needs to learn about)?

The Calling external Code in LabVIEW section in the online help has a very detailed chapter about how to do it from LabVIEW and with some good will can be used for the opposite too. If LabVIEW specific parameters are desirable then he would also have to read the LabVIEW External Code Reference section that describes the functions one can call from an external code to deal with LabVIEW data types.

If the DLL should be generic instead, the same advices apply although to a lesser strict degree as what one would need to follow to allow calling that DLL from Visual Basic as FUNCTION. This means basically:

- no C++ functions, they get decorated to an unrecognizable name

- no C++ interfaces, LabVIEW can not access them in any way

- You can pass C++ object pointers to and from functions but LabVIEW can only treat them as opaque pointer sized integers, there is no way it could access methods or variable members of such an object except using explicit standard C exports of the DLL that accept the object pointer as parameter. This is however dangerous since on the LabVIEW side these objects are simply pointer sized integers and it is rather easy to pass a pointer to object type x to a function expecting object type y, unless the LabVIEW programmer treats those pointers as a private refnum (which will not work for LabVIEW 64 byte since the refnums there seem still to be 32 bits, while a pointer there is 64bits)

- no structures with embedded string or array pointers as parameters

- all string and array pointers need to be passed as separate parameters and preferably with an extra length parameter telling the function how long the allocated buffer is (preferably in # of elements but bytes can work too with some extra effort by the LabVIEW developer).

- in addition to above two parameters types only use scalars of standard ANSI C integer and floating point types as parameters

- strings should be passed MBCS encoded and not as widechar or unicode8, simple ANSI is of course best whenever possible

- they can be either zero terminated C string pointers or Pascal string pointers

- no fancy calling conventions, it's either cdecl or stdcall for Windows and just cdecl for other platforms, if multi platform is needed do only use cdecl as it is the only calling convention supported on all LabVIEW platforms.

- buffers to return data should be allocated by the caller, returning buffers allocated by the DLL is although possible not recommended if the contents needs to be accessed from LabVIEW somewhere and it will require an explicit export to deallocate that buffer later, since LabVIEW can not automatically deallocate memory not allocated by itself

- alignment in LabVIEW clusters is always packed (1 byte), other alignments for C structures need to be explicitly declared to the LabVIEW developer so he can do it on the LabVIEW side by embedding extra filler bytes in the cluster but it is a better idea to actually declare these filler bytes explicitly in the C structure declaration, to avoid misunderstandings between the C programmer and the LabVIEW programmer.

- no function return values other than scalars and string pointers

- document if the function is threadsafe

I guess that is it in a nutshell. Not sure what else you would want to tell a C programmer to make your life not to complicated to integrate his DLL into LabVIEW.

Rolf Kalbermatter

[vugie]

rolfk, you should some day go through your posts concerning calling external code and create wiki article from them

[Rolf Kalbermatter]

rolfk, you should some day go through your posts concerning calling external code and create wiki article from them

It's all there and you have my blessings to put it in the wiki

Rolf Kalbermatter

[crelf]

I'd love to see a similar list of dos and don'ts for DLLs that can be used in TestStand (I'm working with an awesome DLL developer right now who's cursing TestStand for not being able to read pointers to pointers to arrays of pointers to pointers to...)

[Rolf Kalbermatter]

I'd love to see a similar list of dos and don'ts for DLLs that can be used in TestStand (I'm working with an awesome DLL developer right now who's cursing TestStand for not being able to read pointers to pointers to arrays of pointers to pointers to...)

Well LabVIEW can do that sort of but it requires the DLL developer to dig into LabVIEW memory management functions and use them strictly! Of course this is to much asked for most of them.

What I would say is that such an interface is sort of ok to be used from C code only but absolutely unsuitable to be called from anything else, be it Visual Basic, Delphi, and yes even TestStand. TestStand is not a C compiler so it should not be expected to behave like one .

Rolf Kalbermatter

[John Lokanis]

Thanks for the detailed reply! Sorry for not responding sooner but I was on vacation.

The DLL in question will be performing some math on DBL arrays of data. It will not be a 'LabVIEW only' DLL. I think there is enough info here to answer all my questions. Still surprised I could not find this info on NI.com somewhere...

thanks again,

-John

[Cat]

rolfk, you should some day go through your posts concerning calling external code and create wiki article from them

I was just thinking I probably have a post archived away somewhere that Rolf wrote 15 years or so ago on this very topic.

[Rolf Kalbermatter]

I was just thinking I probably have a post archived away somewhere that Rolf wrote 15 years or so ago on this very topic.

Must have been an Info-LabVIEW post then and not as detailed and about all these things. Many things described in the previous answer were not even possible with LabVIEW 4 or so, which was the then most current version. Also at that time while I was busy trying to write the occasional CIN, I was also often flabbergasted at how to match C and LabVIEW well.

Would it be a post explaining about the Windows SDK datatypes and how they relate to LabVIEW datatypes? That could be from around that time.

Rolf Kalbermatter

[Cat]

Must have been an Info-LabVIEW post then and not as detailed and about all these things. Many things described in the previous answer were not even possible with LabVIEW 4 or so, which was the then most current version. Also at that time while I was busy trying to write the occasional CIN, I was also often flabbergasted at how to match C and LabVIEW well.

Definitely info-LabVIEW, and most probably about CINs. I remember I had the post printed out and filed away. I wasn't using CINs enough that I had the process completely down -- not that the "process" was very well defined anyway. But when I did need a CIN, it was very handy to be able to pull that post out and at least have some clue about how to proceed. Things are a lot easier now!

(Yeah, and I used to have to walk 5 miles to school everyday, thru 3 feet of snow. Uphill. Both ways. )